A software defined networking (SDN) is a relatively new type of networking architecture that provides centralized management of network elements rather than a distributed architecture utilized by conventional networks. In a distributed architecture, each network element makes routing, switching, and similar decisions based on the results of traffic processing and a distributed control mechanism. In contrast, in a SDN, a network element follows routing, or switching, decisions received from a central controller.
The operation of a network element can be logically divided into a “control path” and a “data path”. In the control path, control protocols, e.g., for building in routing protocols, a spanning tree, and so on, are operable. In the data path, packets-processing operations are performed on a per-packet basis. Such operations include examining each incoming packet and making decisions based on the examination as to how to handle the input packet (e.g., packet forwarding, packet switching, bridging, load balancing, and so on). Furthermore, in a conventional network, network elements typically include both the control and data planes, whereas in a native SDN, the network elements include the data path, and the central controller implements the control path.
The SDN can be implemented in wide area networks (WANs), local area networks (LANs), the Internet, metropolitan area networks (MANs), ISP backbones, datacenters, inter-datacenter networks, and the like. Each network element in the SDN may be a router, a switch, a bridge, a load balancer, and so on, as well as any virtual instantiations thereof.
In one configuration of a SDN, the central controller communicates with the network elements using an OpenFlow protocol. Specifically, the OpenFlow protocol allows addition of programmability to network elements for the purpose of packets-processing operations under the control of the central controller, thereby allowing the central controller to dynamically define the traffic handling decisions in the network element. To this end, traffic received by a network element that supports the OpenFlow protocol is processed and forwarded according to a set of rules defined by the central controller.
Traffic received by a network element that supports the OpenFlow protocol is processed and routed according to a set of rules defined by the central controller based on the characteristic of the required network operation. Such a network element routes traffic according to, for example, a flow table, and occasionally sends packets to the central controller. Each network element is programmed with a flow table and can be modified by the central controller as required. The operation of network elements and the definition of flow tables according to the OpenFlow protocol are further described in the OpenFlow Switch Specifications issued by the Open Networking Foundation.
Due to the programmability, scalability and other features of SDN architectures, network carriers have started to deploy and utilize SDNs as part of their infrastructures to efficiently handle the vast number of mobile devices accessing their respective networks. The use of such mobile devices (e.g., smart phones and tablet computers) has significantly increased and in many cases, such mobile devices have become a primary replacement for other computing devices.
Network carriers allow access to data by the mobile device through a variety of applications. The data bandwidth consumption (in both directions, i.e., upload and download of data) by applications installed in mobile devices through, for example, cellular networks, tends to congest or overload the network's resources. This is due to, for example, the way applications are programmed, the asynchronous demand for data bandwidth by applications, and the way users interact with applications. For example, an application can be programmed with an embedded security breach that causes unauthorized data transmission over the network to external users. As another example, an application can be poorly programmed to continuously synchronize with application servers, thereby causing misuse of computing and/or network resources. Such misuse of resources is typically not aligned with the carrier capacity planning.
Monitoring and detecting the behavioral impact of applications such as, for example, applications that congest or overload the network's resources, is not a straightforward task. This difficulty occurs due to the number of available applications, the different types of mobile devices, and the sporadic usage of applications. For example, an application can exhibit a security breach when running over an Android® operating system, but not when running on iOS®. In some cases, the same application can operate properly in conjunction with iOS® version ‘x’, but not in conjunction with iOS® version ‘y’.
The complexity of a solution for detecting the behavioral impact of applications lies in the fact that applications are created and/or updated on a daily basis. In addition, the requirements of network carriers with respect to the resources that should be monitored can be different from one carrier to the other.
Existing solutions are limited to monitoring the network traffic to detect a set of predefined network events, such as high packet rates over a particular channel, a high latency between two hops in the network, and an ideal network resource. The existing traffic monitoring solutions are not adapted to detect the root cause of such network events, and specifically the behavioral impact of applications installed on mobile devices. Furthermore, existing traffic monitoring solutions cannot be rapidly modified and/or scaled to monitor different applications, resources and/or events.
Therefore, it would be advantageous to provide a solution that overcomes at least the deficiencies noted above.